home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / SourceCode / MiscKit1.7.1 / MiscKitArchive.mbox / mbox / 000035_sanguish@digifix.com_Fri Sep 24 23:07 MDT 1993.msg < prev    next >
Internet Message Format  |  1994-10-30  |  7KB
  1. Received: from yvax2.byu.edu by maine.et.byu.edu; Fri, 24 Sep 93 23:07:03 -0600
  2. Return-Path: <sanguish@digifix.com>
  3. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  4.  <01H3CDW8Z6BK94GOSM@yvax.byu.edu>; Fri, 24 Sep 1993 23:04:57 MDT
  5. Received: from alaska.et.byu.edu by yvax.byu.edu (PMDF V4.2-13 #4169) id
  6.  <01H3CDW502Z4935TVN@yvax.byu.edu>; Fri, 24 Sep 1993 23:04:51 MDT
  7. Received: from yvax.byu.edu by alaska.et.byu.edu; Fri, 24 Sep 93 23:06:36 -0600
  8. Received: from DIRECTORY-DAEMON by yvax.byu.edu (PMDF V4.2-13 #4169) id
  9.  <01H3CDVTX5GW935OQH@yvax.byu.edu>; Fri, 24 Sep 1993 23:04:37 MDT
  10. Received: from nic.hookup.net by yvax.byu.edu (PMDF V4.2-13 #4169) id
  11.  <01H3CDVOF5OW94GLMW@yvax.byu.edu>; Fri, 24 Sep 1993 23:04:31 MDT
  12. Received: from digifix.com (digifix.digifix.com [198.133.162.23]) by
  13.  nic.hookup.net (8.6.beta.12/0.4) with SMTP id BAA19850; Sat,
  14.  25 Sep 1993 01:04:19 -0400
  15. Received: by digifix.com id AA16731 (5.65c/IDA-1.4.4 for misckit@byu.edu); Sat,
  16.  25 Sep 1993 01:04:07 -0400
  17. Received: by NeXT.Mailer (1.95)
  18. Received: by NeXT Mailer (1.95)
  19. Date: Sat, 25 Sep 1993 01:04:07 -0400
  20. From: Scott Anguish <sanguish@digifix.com>
  21. Subject: Re: MiscKit summary and proposal:  stirring up the ashes
  22. To: yackd@alaska.et.byu.edu (Don Yacktman)
  23. Cc: misckit@byu.edu
  24. Reply-To: sanguish@digifix.com
  25. Message-Id: <199309250504.AA16731@digifix.com>
  26. Content-Transfer-Encoding: 7BIT
  27. Status: RO
  28.  
  29.     Don 'verbose' Yacktman had alot to say about the Misc kit and where he'd like to see it go from here.
  30.  
  31.     I don't think there is much, if anything that I would want to raise an objection to. 
  32.  
  33. (1)  Prefixes...
  34.  
  35.     MiscKit and Misc.  Yes!  This seems like an excellent prefix, and will
  36.     definately cover the kit.  It seems fitting also because Don originally
  37.     called it the DAYMisckit, and although we are getting rid of the DAY part
  38.     it seems fitting that the rest stay.
  39.  
  40. (2)  Licensing issues.
  41.  
  42.     This is such a sniggly issue with everyone, but I agree with Don's
  43.     direction here.  Just PD would mean that it may not be as well
  44.     accepted. 
  45.  
  46. (3)  Maintaining Source
  47.  
  48.     Yes!  I'm curious if there might be some incentive adopt a 'standard'
  49.     revision control system for this.  Something like CVS which is designed
  50.     specifically for multiple users at different locations who may need to
  51.     be editing files at the same time.
  52.  
  53.     An EXCELLENT utility contribution would be for someone to write a front
  54.     end for CVS for NEXTSTEP, then we could use it in the development of the
  55.     kit, and it could be adopted as part of the kit as well.
  56.  
  57. (4)  Commercial apps using the MiscKit
  58.  
  59.     Having to credit the individual contributors in a commercial
  60.     program would also have that same negative effect.  However, being
  61.     required to credit the MiscKit either in the online docs, the info panel
  62.     or the printed docs seems reasonable.
  63.  
  64.     Nobody should be required to distribute the MiscKit to a customer if you
  65.     use it.  However it would certainly be appropriate for them to point
  66.     out how to get it, and should be allowable for them to provide it to the
  67.     customer if they want to.
  68.  
  69. (5)  CDROM distributions:
  70. (6)  Third party distributions:
  71. (7)  Modified distributions must be labelled as such.
  72. (8)  People who modify the source do NOT have to send
  73.  
  74.     No real problems here.  I'm not sure about 7 though.  Do we really want
  75.     the potential problems of people releasing modified versions of the MiscKit
  76.     and then someone trying to get an upgrade and suddenly find that there were
  77.     modifications to basic classes that we didn't adopt, or were not offered.
  78.  
  79. (9)  What will be accepted into the kit?
  80.     (1) creative interface widgets, all of which should be palettized
  81.     (2) abstract things which don't need to be on a palette, but it's OK if
  82.     they are.
  83.  
  84.     What about stuff like development tools that we use in the creation of
  85.     the misc kit?  The proposed CVS interface, perhaps a really smart
  86.     formatted documentation generator [ :-) ].  I've also sent some stuff
  87.     to Don about some ideas for a different style of Digital Librarian. If
  88.     someone is interested in working with the Indexing Kit and can put a
  89.     solid effort into this, I'll send the specs off to them, or perhaps the
  90.     mailing list at large.
  91.  
  92. (10)  For now, it will be up to a developer to ....
  93.  
  94.     Yep.
  95.  
  96.     But this does bring up a question... can everyone agree on the basic layout
  97.     as far as directories go?
  98.  
  99.     /LocalDeveloper/Headers/misckit
  100.     /LocalDeveloper/Documentation/MiscKit
  101.     /LocalDeveloper/Source/MiscKit
  102.     /LocalDeveloper/lib
  103.     /LocalDeveloper/Palettes
  104.  
  105.     are all pretty much supported by NeXT, and thats the way I have currently
  106.     organized things on my drive.   I'm curious how Don has stuff organized.
  107.     Everyone??
  108.  
  109.     I also suggested to Don that we try and organize individual classes under
  110.     SubProj directories that could easily be added to your own projects,
  111.     instead of just linking with a library.
  112.  
  113.     In a case like the ClockView, the organization would be along the lines
  114.     of
  115. ClockView/
  116. -rw-r--r--  1 sanguish wheel        235 Aug  4 10:54 ClockViewInspector.h
  117. -rw-r--r--  1 sanguish wheel       1495 Aug  4 11:02 ClockViewInspector.m
  118. drwxrwxr-x  5 sanguish wheel       1024 Aug 17 16:01 English.lproj/
  119. drwxrwxr-x  5 sanguish wheel       1024 Aug 17 16:01 SubProj.bproj/
  120. -rw-rw-r--  1 sanguish wheel        907 Aug 14 02:23 Makefile
  121. -rw-r--r--  1 sanguish wheel        217 Aug  4 15:37 Makefile.postamble
  122. -rw-r--r--  1 sanguish wheel        265 Aug  4 15:37 Makefile.preamble
  123. -rw-r--r--  1 sanguish wheel         81 Aug  2 20:31 NXClockPalette.h
  124. -rw-r--r--  1 sanguish wheel         69 Aug  2 20:31 NXClockPalette.m
  125. -rw-r--r--  1 sanguish wheel       6148 Aug  4 15:32 NXClockPalette.tiff
  126. -rw-r--r--  1 sanguish wheel        118 Aug  4 10:39 PB.gdbinit
  127. -rw-rw-r--  1 sanguish wheel        677 Aug 14 02:22 PB.project
  128. -rw-r--r--  1 sanguish wheel        336 Aug  2 20:40 palette.table
  129.  
  130. ClockView.bproj/
  131. -rw-r--r--  1 sanguish wheel       1297 Aug 14 02:16 ClockView.h
  132. -rw-r--r--  1 sanguish wheel       9520 Aug 17 15:57 ClockView.m
  133. -rw-r--r--  1 sanguish wheel     113498 Aug 14 02:19 clockstuff.tiff
  134. -rw-r--r--  1 sanguish wheel        118 Aug  4 10:39 PB.gdbinit
  135. -rw-rw-r--  1 sanguish wheel        677 Aug 14 02:22 PB.project
  136.  
  137.  
  138.     So that in your programs you could use the palette in IB, but you could
  139.     just add the ClockView.bproj/ in your code.  That would eliminate the
  140.     Interface Builder stuff, and group the related code together.
  141.  
  142.     Comments?
  143.  
  144. (11)  Each contributor will be recognized with a top-level
  145.  
  146.     Yes! 
  147.  
  148. (12)  Object "owner's" responsibilities should include the
  149.     following:
  150.  
  151.     Yes!
  152.  
  153.  
  154. (13)  I'd like to have a file at the top level, a sort of "to-do" list
  155.  
  156.     Oh yes.  Actually, this is something that we should be talking
  157.     about now on the list.  Even simple stuff would be useful. 
  158.  
  159. (14)  Backward compatibility:
  160.  
  161.     yes, but in order to make this easier, if you are working on a class
  162.     perhaps you should consider putting your class design up for comment
  163.     before hand, so that others can give you input before you commit to it
  164.     and as a result commit others.
  165.  
  166.  
  167.  
  168.  
  169.     That covers about everything I can think of.  So if you have any comments on that, send it to the list and/or to me.
  170.  
  171.  
  172.  
  173.  
  174. --
  175. - Scott Anguish -
  176. sanguish@digifix.com (NextMail)
  177. next-announce@digifix.com (comp.sys.next.announce submissions)
  178.